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(57) Abstract 

A table-driven object for 
I use in a presentation tier (30) of 
a multi-tier program to manage 
information for requests of types 
presentation arid business. An object 
contains properties stored in a table. 
Objects stored in the table contain 
the following: "objType" property, 
used to dynamically configure 
the object; "Set(property, value)" 
method, used to set the value of 
an attribute; n Get(property f value)" 
| method, used to get the value of 
an attribute; "Execute(request)" 
method, used to execute a method 
| for messaging to business tier (31); 
"TurboExecute(request, value)", used 
to execute a method for messaging 
to business layer with reduced 
user input. System supported by 
application framework consisting of 
library for specific use. 
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OBJECT ORIENTED GENERIC SCHEMA TO SUPPORT DATABASE OPERATIONS IN A MULTI-TIER ARCHITEC- 
TURE 

pAP.K^ROUN n OF THE INVENTION 

This application claims priority from U.S. 
Provisional Application No. 60/093,260 filed July 17, 
5 1998. 



1. Field of Invention 

The present invention relates to a method and 
system for the formation and use of a programming 
object whose schema is derived from relational database 
10 tables during program execution, i.e. . a table-driven 

object, and further for applying it selected tiers of a 

multi-tier program. 

2- Description of Related Art 

Over the years, many models have been developed to 
15 aid in the construction of complex software 

applications. Today, object technology is a leading 
model for that task. Breaking down complex 
applications into a collection of simpler objects is a 
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logical step to simplifying the development and 
m aintenance of software. However, object technology i= 
Bot a panacea for every aspect o£ software development. 
Furthermore, in the areas where it does apply, the 
complexity and associated costs of development and 
maintenance can sometimes outweigh the benefits of rts 



use 



Two popular software application design 
methodologies are structured programming and object- 
, oriented programming. Structured programming requires 
the designer to identify the steps a program will taxe 
during execution. The goal of the design phase i. to 
come up with a flow diagram of connected symbols such 
as boxes that represent processes, diamonds that 
5 represent decisions, and cylinders that represent data. 
T he flow diagram represents the flow of execution the 
program will take when executed. Once the design is 
•' completed, modules are developed to implement the 

design. Structured programming design is appropriate 
20 to single-thread type applications (a^, read 
information, if this do this else . . .). 

in an object-oriented application, the designer 
considers the application as a collection of objects 
each containing data called properties, and functions 
25 called methods. Properties and methods form the 
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structure, or schema, of an object. Object models, 
similar to flow diagrams, are developed to aid in the 
construction of an object-oriented application. 
Object-oriented designs are appropriate for event- 
driven applications such as graphical user-interfaces 
(GUIs) that contain text boxes for data entry and 
buttons to execute business requests. 

Today, many teams are required to implement and 
maintain most complex software. For both business and 
technical reasons, each team has different expertise, 
and each uses a different set of tools to accomplish 
its goals. Multi-tier architecture, usually, three- 
tier architecture, is a simple yet powerful way to 
embody an application. In the present specification, 
15 the following terms describe the tiers: 
Presentation Tier: 

The code that collects data from and displays 
information to the user. Simple code 
processing is done in this tier such as 
20 insuring all fields for a request are 

provided. 

Business Tier: 

The code that processes the user's requests. 

Data Tier: 
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The code that manages the data as well as the 
data tier itself. 
The programming team for the presentation tier 
needs an understanding of how to collect information 
from and display information to the user. The 
programming team for the business tier needs to 
understand how to accomplish business requests and 
enforce business rules such as security. Finally, the 
data tier team will need to understand the various 
business requests and their frequency to optimize 
performance in fulfilling requests. 

Each team will not require the same tools since 
each team usually use an architecture suited for its 
requirements. Most data tiers are built using 
relational database management systems (RDBMS) , not 
object-oriented databases (OODBMS) . Database 
architects employ entity relationship models to design 
" a database, and structured query language (SQL) to 

implement them. The business tier is typically built 
by business programmers who employ structured design 
techniques to design an application, and a high-level 
programming language such as COBOL to implement it. 
Languages that have built-in support for objects such 
as C++ can perform these operations, but the simplicity 
of a high-level programming language such as COBOL, 
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allow programmers to focus on business rules, not 
implementation details. 

The presentation tier is a complex layer of event- 
driven software that is controlled by the user using 
the I/O devices 5 of the computer. The presentation 
tier is usually composed of -a form with graphical 
controls such as text boxes for data entry and buttons 
for executing a request. The presentation tier 
benefits most from object technology because the forms 
and controls the user works with can be represented as 
objects. Here, object-oriented programmers design 
interfaces using object-oriented models such as 
Rumbaugh's Object Modeling Technique (OMT) and an 
object-oriented language such as C ++ is used for the 

15 implementation. 

The added power that comes with an object-oriented 
design has two drawbacks - complexity and cost. These 
" drawbacks apply to both the initial implementation and 
the maintenance that follows. This is because 
languages that directly support objects, such as C ++ , 
do so through the use of special programming language 
structures. These structures enable a programmer to 
define an object's schema (fljL su, properties and 
methods) . As an object matures, its schema inevitably 
becomes more complex more properties and methods 
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are added, .ore code for each 1. added, . additionally, 
experienced pro,™* are trained to recogni 2 e common 
objects, then breax them down into a series of objects 
that share code with each other using an object- 
oriented technique called inheritance. It is also 
co^on to have one object contain other objects. 

-TlMlffTY AF THE TNVF.NTIQW 
It is therefore a general advantage o£ the present 
invention that a method and apparatus are provided 
, having flexibility in creation of programing objects. 

It is a more particular advantage of the present 
" invention that a method and apparatus are provided in 
which a programing object is created whose target 
schema is derived from database tables in a database, 
5 with a properties table and a methods table to 
implement the target schema. 

It is another advantage of the present invention 
that a method and apparatus of the type described are 
provided in which objects with different schemes can be 
20 created dynamically from one generic schema. 

It is a further particular benefit of the present 
invention in that a method and apparatus are provided 
in which one instance of a table-driven object can 
mutate dynamically from one run-time schema to another. 
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It is also a particular benefit of the present 
invention in that a method and apparatus are provided 
in which a library of complex objects, each targeted 
for a specific use, can be reduced to one object and 
its supporting tables, reducing both costs and 
complexity of development and maintenance. 

Briefly stated, in accordance with the present 
invention a method and apparatus are provided for 
creating a programming object using database tables - a 
table-driven object. A table-driven object is an 
object with a generic schema, whose target schema is 
derived from database tables, not the programming 
language it was implemented in. It requires an object- 
oriented language which is used to implement the 
generic schema, and a database with a properties table 
and a methods table to implement the target schema. 
One instance of a generic schema is composed of one 
property and four methods: 

1. objType property. 
2Q 2. Set (property, value) method 

3. Get (property, value) method 

4. Execute (request) method 

5. turboExecute (request, value) method 
The objType property is used to configure an 

25 object, and it does this by dynamically reading the 
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appropriate properties from a database into a memory 
device. The ob j Type property will determine how many 
properties are included in one object. Set (property, 
value) provides the mechanism to set the value of a 
virtual property, Get (property , value) provides the 
mechanism to retrieve the value of a virtual property, 
and Execute (request) is used to communicate a business 
request to the business tier using the object's 
properties. The turboExecute method is a mechanism for 
quick execution of a business request whereby a subset 
of property values are provided, while others are 
defaulted. 

mfF nfl grPTPTTO M T T HF nBAWINGS 
The means by which the foregoing objects and 
features of the invention are achieved are pointed out 
in the claims forming the concluding portion of the 
specification. The invention, both as to its 
organization and manner of operation may be further 
understood by reference to the following description 
0 taken in connection with the following drawings. 
Of the drawings: 

Figure 1 is a hardware diagram of a computer 
system in which the present invention is embodied; 



WO 00/04445 PCT/US99/16152 

9 

Figure 2 illustrates an example properties table 
that contains the properties of an object and each 
property's attributes; 

Figure 3 illustrates an example methods table for 
further defining a table-driven object; 

Figure 4 is a block diagrammatic representation of 
a portion of the present system illustrating a three- 
tier architecture with tables and memories in which the 

tables are located; 

Figure 5 is a flow diagram detail of Figure 4 
illustrating the sequence of steps performed as a 
result of setting the table-driven object's objType; 

Figure 6 is a flow diagram detail of Figure 4 
illustrating the sequence of steps performed as a 
result of calling the table-driven object's Set Method; 

Figure 7 is a flow diagram detail of Figure 4 
illustrating the sequence of steps performed as a 
result of calling the table-driven object's Get Method; 
Figure 8 is a flow diagram detail of Figure 4 
0 illustrating the sequence of steps performed as a 

result of calling the table-driven object's Execute 
Method; 

Figure 9 is a flow diagram detail of Figure 4 
illustrating an example sequence of steps to accomplish 
25 a turbo business request; 
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Figure 10 is sample code that illustrates the 
creation of a table driven object, setting its 
properties, executing a business request, then reading 
the results back; and 

Figure 11 is sample code that illustrates the 
creation of a table driven object, executing a turbo 
business request, then reading the results back. 

pF.sr.RTPTTON OF THE PREFERR ED EMBODIMENTS 

Referring to Figure 1, the method of the present 
invention may be practiced on and embodied in a 
computer terminal 1. The computer terminal 1 includes 
a computer 2 having a memory 3, central processing unit 
4, and input/output unit 5. Input /output devices 
including a monitor 10, keyboard 11 and mouse 12 are 
each coupled to the input/output unit 5. Additionally, 
the input /output unit 5 communicates with a database 20 
which may be accessed via a network 22 or in other 
known ways . 

In the present description, Figures 2 and 3 
i illustrate tables used in forming a table-driven 

object. Figure 4 is an illustration of three-tier 
architecture illustrating tables and memories and their 
location. Figure 5 is an illustration of the method 
for setting the object type. Figures 6 and 7 are 
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iiiustrations of the steps performed in response to 
calling a Set method and a Get method respectively. 
Fig ur. 8 illustrates the response to calling the 

, hod and Figure 9 is a flow diagram 
Execute method ana exy 

^ of step for turbo business 
illustrating the sequence of step 

requests . 

n: mirP 2 illustrates one 
More specifically, Figure 

cable 24. In the presentation 
example of a properties table 

tier, an object's properties manage information for 
, presentation an* business revests. The table-driven 
object accomplices this by having all of its 
properties in a table ana associating attributes to 
each property. The properties and associated 
attributes are loaded into memory 64 (Figure 5, as a 
s result of setting the obJType property, and property 

values are set and retrieved using Set and Get methods 
as shown in Figures 5, 6, and 1 respectively. Setting 
' the obJType type causes the appropriate properties to 
be loaded from the properties table 24 into memory, and 

,„ »„ obiect's schema is done in the table 
20 any changes to an object 

24 using known methods for adding, changing, and 
removing rows in a 'table, not in the programming 
ianguage. This includes adding new properties (add a 
new row to table) , deleting existing properties (delete 
25 a row from the table) , and changing the attributes of a 



WO 00/04445 PCT/US99/1 6152 

12 

property (update a row in a table). Changes^ objects 
are available immediately by simply setting the 
objType. This is in contrast to coding changes 
directly into the object, rebuilding the object, 
, deleting the older version of that object, and 
installing the newer version. 

A table-driven object is an object with a generic 
schema implemented in a programming language, and a 
target schema derived from database tables, not a 
0 programming language. It requires an object-oriented 

la nguage which is used to implement the generic schema, 
and a database 20 with a properties table 24 and a 
methods table 26 to implement the target schema. One 
example of a preferred generic schema is composed of 
15 one property and 4 methods to accomplish this: 

1. objType property. 

2. Set (property, value) method 

3 . Get (property, value) method 

4. Execute (request) method 

2Q 5 . turboExecute (request, value) method 

Table 24 in Figure 2 is one example of how the 
objType property is set. Different properties, each of 
which will be in the database 20 (Figure 1), are 
specified for the object of the present example. In one 
25 example in accordance with the invention, consider a 
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trade entry application whose users work with products 
and instruments. Such an application could contain a 
Spot product that facilities the trade of one 
instrument for another (e_cu, U.S. Dollars for Japanese 
Yen) , and a Deposit product that facilitates the 
deposit of some instrument such as U.S. Dollars over a 
specified time. Traders will enter product data then 
make a request such as "Edit" which checks the deal 
(requested trade) for validity, and "Commit" which 
writes the trade. "Edit" and "commit" are the methods 
in the present example, further described with respect 

to Figure 3, 26. 

in the example, the properties include "User 
name," "Trade ID," "Company," "Changed" and "Notes" 
(Figure 2, 24). These property names will be given 
property IDs 1-5 respectively. In each case the 
request Id for edit will be 1. Default values for a 
" subset of properties are entered for provision in the 
"turboExecute" mode. In the present examples, the 
0 values will be null, or blank in the case of the user 

name, trade ID, change and notes. The company name . 
will be defaulted in the case of a Spot object. The 
table 24 also specifies that a user can request a 
"turboExecute" form of communication further described 

25 below- 
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With the properties in memory, there are 2 options 
for iterating through all of an object's properties. 
Using known methods supporting the structure 
implemented, nodes in memory 64 (Figure 5, can be 
.■walked. ■ Alternatively, the table 24 (Figure 2, can 
be queried such that all rows for a given object 
name/type are returned. From these rows, the id's can 
be retrieved and used as input to the Get method of 
Figure 7. This methodology can be used to build 
argument lists for business processing. By adding a 
req uest identifier and a parameter number column to the 
properties table 24, properties can be dynamically 
ma pped to a business request. For any business 
request, the object has all the information needed to 
5 gather the arguments for a request allowing it to 

perform the call. This is explained in more detail 
below . 

The implementation of virtual properties must 
scale, complex objects will have a large number of 
,„ properties, and the user must be able to set them or 
retrieve them without any noticeable performance 
penalty. If there are 1,000 properties,, assigning a 
value to the 1.000 th property should not take any more 
time than assigning a value to the first. This argues 
25 for an indexing scheme in which the property name is 
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indexed. Since properties reside in the database 20 
(Figure 1), one option is to have their values reside 
there, effectively making them persistent. Persistent 
presentation objects address the scaling issue 
mentioned above, however, the overhead of this for 
every access is usually too great for. an object that 
changes as frequently as a presentation object. For 
performance reasons, the presentation object's 
properties should be read from the database 20 and 
stored in memory using known organizations that support 
quick updates and retrievals based on an index (fiJU, 
B-tree), where the index is the property name. 

Figure 3 illustrates an example of a methods table 
26 associated with the table-driven object of Figure 2. 
Execute is the mechanism that uses table 2 6 to perform 
a business request. Additionally, TurboExecute is a 
mechanism for quick execution of a business request 
whereby a subset of object attributes are provided with 
property values while others are set to default values 
0 in accordance with the defaults column in table 24 of 
Figure 2. The object of the present example will also 
include the methods "Edit" and "Commit" as shown in 
table 26 in Figure 3. The "Edit" method is for 
allowing a user to submit a trade for checking by the 
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sy3 te.u. The -co-if method is for actual ordering of 

a trade. 

A preferred embodiment of the multiple tier 
architecture is illustrated in Figure 4. The computer 
■ 2 {Fig ure 1) has a presentation tier 30, business tier 
31 and data tier 32. The tiers 30-32 are stored in the 
computer 2 in a known manner. An interface layer 34 
and the table-driven objects are included in the 

. 4--^ tier 30 Persistent data required for 
presentation tier ju- 

• , processing is located on a disk 38 and is 

.0 business processmy 

coupled to and interfaces with data tier 32. 
Persistent data required for the invention is located 
ln methods table 26 and properties table 24. Memory 40 
is required to temporarily hold data to support the 
15 methods of table-driven objects. 

in operation, as illustrated in Figure 5, the 
object's objType is supplied as seen at box 60. At box 
- 61, the objectType is retrieved from table 24- (Figure 
4) using known methods (flJw select * from Properties 
20 ' where Properties . obj N ame=objType) . If none appear, that 
is no rows are returned from the query, as indicated at 
box 62, the command is returned with a message. When a 
proper object type is detected, as indicated at box 63, 
all rows from the properties table 24 residing on disk 
25 65 are read into the memory device 64. Preferably each 
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node in the tree of the memory device 64 should be 
indexed by the property ID using known methods and each 
node should contain all columns of the properties table 
24 in addition to a field that will hold the value. 

In order to provide values to be used for the 
object, the Set method is called (Figure 6) . The 
proper ID is supplied at box 70, and as seen at box 71, 
known searching techniques are applied to the memory 64 
(Figure 5) to find a node representing the property 
queried. If a node with this ID is not located in 
memory 64, then at box 72 an appropriate message is 
returned. If the search results in a found node for 
that particular ID, then operation proceeds to the box 
73, where using the node found in memory 64 from the 
search in 71, the value for this property is changed 
within the node to the value passed in. 

The Get method is illustrated in Figure 7. A 
property ID is supplied and read as indicated at box 
80. Then at box 81, known searching techniques are 
, applied to the memory device 64 of Figure 5 to produce 
a search result. If a node with this ID is not located 
in memory 64, then at box 82 an appropriate message is 
returned. If the search results in a found node for 
that particular ID, then operation proceeds to the box 
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83, where the value for this property is retrieved. from 
within the node and returned. 

Business requests are executed by the business 
tier 31 (Figure 4), not the presentation tier 30. The 
presentation tier 30 collects the information required 
for the request, then passes selected information to 
the appropriate module in the business tier 31 for 
processing. Referring now to Figure 8, the Execute 
method in the table-driven object simplifies all 
business requests by centralizing them to one method 
with an argument that identifies the request. The 
Execute method will collect the arguments required for 
the request using the request ID and parameters column 
in the properties table 24 (Figure 2) , and call the 
, appropriate business processing module as shown in 

Figure 8. At box 90, an ID is supplied and read. If 
this is not a valid ID as measured at box 91, then at 
' box 92, the request is returned with an appropriate 

message. A valid request initiates progress to box 93 
0 at which the business program arguments are built by 
retrieving the parameters for that request sorted by 
parameter number as indicated in the property table 24 
and subsequently the values for those parameters are 
retrieved from the memory device 64 (Figure 5). At box 
25 94, the module name is retrieved from the methods table 
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26 (Figure 3) and the request is executed by calling 
the business module associated with that request with 
the specified parameters. 

The invention provides, sucu, Figure 4, for 
dynamic methods by employing a methods table 26 that 
contains the requests, a request identifier, and the 
associated business processing module name, and adds a 
column to the properties table 24 that contains the 
request identifier. Specifically, the invention allows 
for an interface 34 to query the properties table 24 
for a particular objectType and determine the business 
requests it can perform by checking for those that have 
non-zero arguments. It can then use the methods table 
26 to display the requests available for the selected 
object type to the user. When the user instructs the 
interface 34 to perform one of the business requests, 
the object looks up the identifier of the request being 
made, queries the properties table 24 for all 
properties associated with that request, gathers the 
values for those properties using the Get method of 
Figure 7, and executes the appropriate business 
processing module which it retrieves from the methods 
table 26 using the data from the properties as 
parameters to the call. 
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Sample programming code for creating a table- 
driven object, executing a business request and 
retrieving the results is contained in Figure 10. 

The table-driven presentation object also provides 
5 for business requests that can be entered by the user 
in one line - a turbo business request. Some business 
requests require many pieces of information, and users 
may find these too time consuming - especially if most 
of the information is constant. A turbo business 
10 request allows a user to enter a subset of the 

parameters on one line. The turbo business request is 
accomplished by adding the defaults and turbo request 
columns to the properties table 24. The user enters one 
line of information which corresponds to a subset of 
properties for a particular table-driven object. The 
sequence of steps in a preferred embodiment for turbo 
business requests is shown in Figure 9. 

Specifically, a turbo request is submitted by the 
user and received at box 100. Here the request is 
"Spot JDOE USD DEM 1000". Using known parsing 
techniques, the first word is identified as spot and 
subsequently, a spot object is created. At box 100, 
properties for a table-driven object representing a 
spot exists in the memory device 64 (Figure 5) by 
creating a table-driven object and setting its object 
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type equal to "Spot." This creation of the spot 
comprises the "objType" property of Figure 5, As seen 
at box 101, using the properties table 24, default 
values for a "Spot" object are moved into the memory 
5 device 64. At box 102, table 24 is used to obtain the 
default values for a "Spot" object. The remaining 
portion of the request, "JDOE USD DEM 1000" is parsed 
according to known techniques and using the information 
in table 24, values for username and other fields are 
10 set. And as indicated at box 103, the Execute method 
of Figure 8 is performed to provide a complete object 
for performance of an edit or a trade. Upon some user 
action, such as a hitting an enter key or a button 
pr ess, the table-driven object is instructed to execute 
15 the turboExecute method. 

The turboExecute method first moves the default 
values for the business request parameters into the 
" memory 64 (Figure 5). It then parses the line entered 
using the turbo request column of the properties table 
20 24 to determine the line format, and effectively fills 
in the values of a subset of properties. Finally, it 
calls the Execute method. Variations such as per user 
defaults and turbo line formats can be accomplished by 
adding a user column to the properties table 24, or 
25 breaking the properties table 24 into two tables - one 
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for the properties, object name, and business request 
information, and one for the user's defaults and turbo 
format . 

in this example, the application is built on a 
three tier architecture where the business tier 31 
(Figure 4) is implemented in COBOL and the presentation 
tier 30 is implemented in Microsoft's Visual Basic. 
The COBOL tier has an interface program that accepts a 
module name and arguments from the presentation tier 
30, and calls the appropriate COBOL module with those 
parameters to execute that request. Errors and 
warnings are returned to the presentation tier 30 
through the arguments (e^, a status and message 
property) . The business tier 31 is physically 
decoupled from the presentation tier 30, and requests 
between the presentation tier 30 and the business tier 
31s are accomplished using messaging middleware (e_cu, 
? ' a message containing the request and the parameters is 
sent over a network to a receiving program that 
20 executes it) . The presentation tier 30 includes two 
layers - an interface layer 34 and a table-driven 

object layer 36. 

The interface layer 34 is a collection of forms 
written in Visual Basic that gather data from the user 
25 for a particular product (e^, Spot) . Once the user 
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enters the data for a spot, a request such as edit, 
which checks the trade, is executed. Upon receipt of a 
business request from the presentation tier CUe^, a 
button click) , the interface code builds a spot object 
by initializing a table-driven object and setting its 

type to spot. 

Consequently, the table-driven object loads all 
spot properties from the properties table 24 into the 
memory 64 . 

The interface code then sets the values of the 
properties from the form and possibly other values it 
obtains from a database itself, or it calculates, using 
the Set method of the table-driven object (Figure 6) . 
After setting all of its properties values, the table- 
; driven object is instructed to call the Execute method 
(Figure 8) with the Edit parameter by the interface 
layer 34 . 

The calling of a remote business processing 
program in Box 94 (Figure 8) is accomplished via 
0 messaging middleware, where the message contains the 
business interface program module name and parameters 
it requires. After sending the request to the 
appropriate business module, the interface layer 34 
(Figure 4) blocks until the business module returns. 
Upon return, Execute refreshes its properties using the 
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parameters returned from the business tier 31, and 
returns control back to the interface 34. The 
interface 34- uses the Get method illustrated in Figure 
7 to examine fields that represent errors and warnings, 
and flushes selected properties of the spot object to 
the form for user display. 

Sample code for creating a table-driven object, 
executing a turbo business request and retrieving the 
results is shown in Figure 11. 

The invention reduces costs of development and 
maintenance by providing an object with a simple 
interface that supports many types of objects. There 
is a reduction in the size of an application built with 
these objects, the object library itself, and the 
amount of overall memory required by the application. 
Specifically, given an application built employing 
standard object technology and one based on the table- 
" drive object model of this invention, some preliminary 
results in the context of the application discussed in 
20 the specification are as follows: 

Application: 19% decrease 
Object Library: 59% decrease 
RAM: 16% decrease 
Also, moving from one interface to another is much 
simpler. For example, a browser version of the above 
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application may be accomplished by recoding the 
interface in HTML and having it create table-drive 
objects, set properties, and execute business requests 
as was done with the application employing Visual 
Basic. 

In applications where the presentation tier 30 
(Figure 4) performs complex business processing, it may 
be advantageous to employ a layer of standard objects 
that receive requests from table-driven objects in 
accordance with the invention. This would permit 
inheritance of one object from another and one object 

to contain another. 

It should be recognized that every application can 
benefit from applying the table-driven object of this 
invention to the presentation tier 30 of the 
application. Legacy-type systems, in particular, 
however, benefit significantly from the table-design 
object of the invention. For example, without any code 
rewrites, legacy applications and their data become 
) accessible to the latest presentation technology. New 
presentation technology becomes more of an add-on than 
a rewrite. For legacy applications the method of a 
preferred embodiment of this invention includes the 
following steps: 



WO 00/04445 PCT/US99/16152 

26 

1. Break down the target application into 3 
tiers. 

2. Define the interface portion of the 
presentation tier (forms, etc.). 

3. Identify the business requests and their 
parameters required for the business tier. 
If necessary, create one or more business 
request processing programs in the business 
tier . 

4. Build the table for the table-driven object 
to accomplish the requests of 3 and the 
interface of 2. 
5. Implement the interface, create and populate the 
table-drive object, and send the requests in. 
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CLAIMS 

1 1. A method for forming a table-driven object for 

2 use in a multi-tier architecture comprising the steps 

3 of forming a generic schema in an object oriented 

4 computer language and providing a database with a 

5 properties table and a methods table for implementing a 

6 target schema, the generic schema comprising at least 

7 one property and a plurality of methods, the property 

8 defining a preselected group of properties to be read 

9 from a database into a memory device housing a target 

10 schema, at least one said method for determining values 

11 to be assigned to and at least one said method for 

12 determining values to be retrieved from attributes in 

13 said target object and at least one said method for 

14 communicating with a business tier of said architecture 

15 for utilizing the target object in a business request; 

16 invoking said at least one method for determining 

17 attribute values and storing attributes of said target 

18 object in the memory and invoking said at least one 

19 method for communicating with said business tier for 

20 providing said object thereto. 
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2. The method according to Claim 1 further 
prising the step of providing attributes available 
said database and selectively altering properties of 



WO 00/04445 PCT/US99/16I52 

28 

said generic object for providing for dynamic mutation 
of object attributes. 

3. The method of Claim 1 wherein the step of 
> providing at least one method for updating attribute 

3 values comprises providing a Set method and providing 

4 means for responding to invocation of said method for 

5 providing a value for each property of the object. 



1 
2 
3 
4 
5 



4. A method according to Claim 1 wherein the step 
of providing at least one method for determining an 
attribute value comprises a Get method and further 
comprising the step of providing means for responding 
to invocation of said get method for returning to the 

6 object a corresponding value determined by said get 

7 method. 

i°" 5. A method according to Claim 1 wherein said at 

2 least one method for communicating comprises an Execute 

3 method for communicating a business request to the 

4 business tier including the object properties. 
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6. A method according to Claim 1 where said at 
least one method for communicating comprises a turbo 
execute method and the step of communicating further 
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1 comprises communicating a limited number of attribute 

2 values determined in accordance with the properties 

3 table and for communicating default values for 

4 preselected attributes. 

1 7 . An apparatus comprising means for storing a 

2 target object for provision to a presentation tier in a 

3 multi-tier architecture, said means comprising an 

4 object memory for storing a target object, a database 

5 storing values for association with attributes of a 

6 target object, tables for storing methods and 

7 attributes for target objects, means for storing a 

8 generic object and means for invoking said generic 

9 object, and means for loading said object memory in 

10 response to reading of said tables as commanded in 

11 accordance with said generic object, said target object 

12 being accessible to response to further commands. 

x 8 . An apparatus according to Claim 7 further 

2 comprising means for commanding coupling of said stored 

3 object to a business process in a multi-tier 

4 architecture for handling user requests in a 

5 presentation tier and data manipulation in a business 

6 tier, and means storing an object having attributes and 

7 methods, means for communication with said object to 
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1 provide values for attributes therein in the user tier 

2 and means for coupling said object as an element in 

3 business requests in said business tier. 



1 
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9. A method for performing a transaction 

2 comprising the steps of storing a generic object, said 

3 object comprising at least a set of properties and 
methods for communicating with a presentation layer for 

5 determining object attribute values and for 

6 communicating with a business layer for performing a 
transaction; commanding construction of a target 
object; accessing values from a database for provision 
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9 to said target object memory; and coupling the 
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attributes of said target object in a transaction. 



1 10. An apparatus for performing a transaction 

2 comprising a presentation tier which determines object 



attribute values, a business tier which performs a 
transaction and means for commanding communication 
between said business tier and said presentation tier, 
means for commanding construction of a target object, 
said means for commanding communication with said 
presentation tier comprising means for accessing values 
from a database for a provision to said target object 
memory and wherein said means for communicating with 
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said business tier comprises means for coupling the 
attributes of said target object in a transaction. 

11. An apparatus in accordance with Claim 10 
further comprising means for dynamically mutating the 
target object. 

12. An apparatus in accordance with Claim 10 
wherein said means for dynamically mutating comprises 
means for selecting at least one differing attribute 
from said database for inclusion in said target object. 



WO 00/04445 



1/9 



PCT/US99/16152 




11 

/ 



12- 



□ □□□□ 

□ □□□□ 




— 10 



FIG. 1 



SUBSTITUTE SHEET (RULE 26) 



WO 00/04445 

2/9 



PROPERTY 


PROPERTY 


OBJECT 


REQUEST 


PARAM 


DEFAULTS 


TURBO 


NAME 


ID 


NAME 


ID 


NUMBER 




REQUEST 


USERNAME 


1 


SPOT 




1 


NULL 


1 


TRADE ID 


2 


SPOT 




0 


NULL 


0 


COMPANY 


3 


SPOT 




2 


BB 


0 


CHANGED 


4 


SPOT 




0 


NULL 


0 


NOTES 


5 


SPOT 




3 


NULL 


0 



FIG. 2 



26 




REQUEST NAME 


REQUEST 
IDENTIFIER 


REQUEST MODULE 


EDIT 


1 


cblEDIT 


COMMIT 


2 


cblCOMMIT 



FIG. 3 



PCT/US99/16152 




SUBSTITUTE SHEET (RULE 26) 



WO 00/04445 



PCT/US99/16152 



3/9 



34 

EXECUTE 



PRESENTATION TIER 



INTERFACE LAYER 



TABLE-DRIVEN OBJECTS 



BUSINESS TIER 



DATA TIER 



26- 
METHODS 
TABLE 



38 

BUSINESS 
PROCESSING 



^30 
GET/SET 



MEMORY 



objTYPE 
-31 



-32 



-24 

PROPERTIES 
TABLE 



-40 



FIG. 4 



SUBSTITUTE SHEET (RULE 26) 



WO 00/04445 



PCT/US99/16152 



4/9 



READ 
objTYPE 



-60 



T 
65 



-61 



ISTHISAVALID 
OBJECT TYPE? (NAME 
IN PROPERTIES TBL?) 



N 



RETURN 

WITH 

MESSAGE 



62 



MEMORY 



READ ALL ROWS FOR THIS 
objTYPE FROM PROPERTIES TABLE 
24 RESIDING ON DISK 65 INTO 
MEMORY 64 ORGANIZING THEM 
INTO A KNOWN INDEXING 
STRUCTURE (E.G.BTREE) 

7 



ID: 3 

COMPANY 



1D:1 




ID: 5 


U/NAME 




NOTES 



-64 



63 



FIG. 5 



SUBSTITUTE SHEET (RULE 26) 



WO 00/04445 



PCT/US99/16152 



5/9 



READ PROPERTY 
ID SUPPLIED 




USING THE NODE FOUND 
IN MEMORY 64 FROM THE 
SEARCH IN 71, CHANGE 
THE VALUE CONTAINED TO 
THE VALUE PASSED IN. 



RETURN 

WITH 

MESSAGE 



■72 



-73 



FIG. 6 



SUBSTITUTE SHEET (RULE 26) 



WO 00/04445 



PCT7US99/16152 



6/9 



READ PROPERTY 
ID SUPPLIED 




USING THE NODE 
FOUND IN MEMORY 64 
FROM THE SEARCH OF 
81, RETURN THE VALUE 
CONTAINED. 



FIG. 7 



SUBSTITUTE SHEET (RULE 26) 



WO 00/04445 PCT7US99/16152 

7/9 




/-92 



IDENTIFY ALL ARGUMENTS 
REQUIRED FOR THIS REQUEST 
USING TABLE 24, THEN 
RETRIEVE THE VALUES FOR 
THOSE ARGUMENTS FROM 
MEMORY 64. 



Y 



RETRIEVE THE MODULE NAME 
FROM THE METHODS TABLE 2 
USING THE REQUEST ID AS AN 
INDEX, AND EXECUTE THE 
REQUESTBY CALLING THE 
BUSINESS MODULE WITH THE 
PARAMETERS FROM 93. 



FIG. 8 



SUBSTITUTE SHEET (RULE 26) 



WO 00/04445 



PCT/US99/16152 



8/9 




101 



PARSE TURBO LINE USING 
KNOWN TECHNIQUES AND 
IDENTIFY ASASPOT-CREATEA 
TABLE-DRIVEN OBJECT AND SET 
THE objTYPE = "SPOF (FIG. 5) 



102- 



I 



USING THE PROPERTIES TABLE 24, 
MOVE ALL DEFAULT VALUES FOR A 
SPOT OBJECT INTO MEMORY 64. 



103- 



I 



PARSE THE REMAINDER OF THE 
TURBO LINE ENTERED USING KNOWN 
TECHNIQUES AND IDENTIFY THE 
PROPERTIES ENTERED USING THE 
TURBO REQUEST COLUMN OF THE 
TABLE 24 AS THE FORMAT. 



104' 



)-TURBOEXECUTE 
METHOD 



CALL THE EXECUTE METHOD OF FIG. 8. 



FIG. 9 



SUBSTITUTE SHEET (RULE 26) 



WO 00/04445 



PCT/US99/16152 



9/9 

// declare the table-driven object 

TDObjectmyTDObject; 

interrorCount; 

// create a Spot product object by loading all rows from table 24 with Spot as 
// Object Name into a memory device similar to Figure 5. 
my7DObject.objType = "Spot"; 

// set usemame property 

myTDObject.Set("Usemame";jDOE"); 

// other properties required for a business request to follow 

// such as instruments to trade, how much, who to trade with, etc. 

// execute an edit request - check the trade 
myTDObjectExecute("Edit"); 

//check for errors 

myTDObjecLGet("ErrorCounr,&errorCount); 
if errorCount > 0 then { 
//error handler 

} 

FIG. 10 



// declare the table-driven object 

TDObjectmyTDObject; 

interrorCount; 

// create a Spot product object by loading all rows from table 24 with Spot as 
// Object Name into a memory device similar to Figure 5. 
myTDObject.objType = "Spot"; 

// execute an edit request - check the trade 
myTDObje&turboExecute("Edit", "JDOE", etc.); 

//check for errors 

myTDObjectGetC'ErrorCounr.&errorCount); 
if errorCount >0 then { 
//error handler 

} 
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